When a host application requests the transmission of Fibre Channel (FC) frames to move data from host memory to a storage system, many preparation steps are needed before the frames can be transmitted over a FC link. It is up to lower levels of abstraction, namely the hardware or onboard firmware of a host bus adapter (HBA) or input/output controller (IOC) to segment the host data into units that are consistent with FC frames and to also insert/delete/pass any necessary protection information into the stream of data. When data is moved from host memory and is protected by protection information, there is a contraction or expansion of the actual data length that must be taken into account when mapping the host data to FC frames.
In previous generations of products, the tasks outlined above were carried out mainly by an integrated processor in the HBA. With the increasing use of protection information such as the T10 protection information standard in data transmission, these tasks and calculations have become increasingly complex and taxing on the processor. As FC link speeds increase, link rates are outpacing the processing power/clock speeds of processors that can be integrated into a microchip.
FIG. 1 illustrates an exemplary conventional system 100 for transferring data between a host computer and targets over a communications network. In FIG. 1, a host computer 102 is capable of sending or receiving data to and from targets 104 connected over a communications network 106 such as a Storage Area Network (SAN). Communications link 108, which enables communications between the host computer 102 and the targets 104, may operate under any one of the known networking protocols such as FC.
The host computer 102 typically includes a host processor 110, host memory 112 for storing application data 114, and a driver 116 for communicating with an IOC or an HBA 118 using a computer system bus 120 such as Peripheral Component Interconnect Express (PCIe). The HBA 118 provides connectivity between the host computer 102 and the targets 104, and typically includes firmware 134 and a local processor 122 such as an Advanced RISC Machines (ARM) processor. In addition, the HBA 118 may also include a Direct Memory Access (DMA) engine 124 and local memory 126. The DMA engine 124 may include hardware operating under the control of the local processor 122, and serves to offload the host processor 110 by performing data transfers to and from the host memory 112 with minimal intervention from the host processor. For example, data to be transferred from the host memory 112 to a target 104 may be formatted and placed in local memory 126 by the DMA engine 124 for subsequent transfer to a target. For frame-based communication links 108, the data (which is not typically arranged in frame-sized blocks) may be formatted into frames using firmware 134 executed by local processor 122 and stored in local memory 126 prior to being transmitted over the link as frames of data 128. The local memory 126 may be organized into contiguous frame-sized blocks for storing frames of data.
In the conventional system of FIG. 1, the local processor 122 had to keep track of the boundaries between frames while formatting the data into frames and storing it into frame-sized blocks. Another engine (not shown in FIG. 1) may be responsible for performing data transfers between the local memory 126 and devices connected over the communications link 108.
The system of FIG. 1, with local processor 122 involvement in the data transfer process, works well for data rates of up to about 4 Gigabits per second (Gbit/sec). However, state of the art networks can operate at speeds of up to 8 Gbit/sec or more, which can be too fast for the local processor 122.
In addition, the T10 protection information standard, the contents of which are incorporated herein by reference, now requires that additional check bytes or data integrity fields (DIFs) 130 be inserted into the data to provide end-to-end data protection and verification. Each check byte 130 may be associated with a certain number of bytes of real data 132, which may correspond to sectors in the disks that store the data. The check bytes 130 are a function of the data they protect, but can be stripped off, passed or inserted after transmission, and stored along with the real data. The size of the protection data 130 (e.g. eight bytes for T10) and real data 132 being protected is configurable, as is the alignment of the protection data 130 within a frame. Therefore, in the context of a write command, these check bytes or protection data 130 must be computed, mapped and inserted into different places within the real data 132 of a frame in accordance with the type of disks in the target that will be storing the data, which may change from frame to frame. In the system of FIG. 1, the T10 protection standard requires that the local processor 122 control the identification of the type of data protection, what data to read from host memory 112 in view of the type of data protection, and where the check bytes are to be placed in the local memory 126 along with the actual data. However, the local processor 122 may not be able to perform these control functions along with formatting the data into frames and keep pace with the speed requirements (link rates) of state of the art networks.
Therefore, there is a need for mapping protected data into frames in a manner that minimizes the involvement of a local processor in a HBA or IOC.